[ROCm] Rework ROCm build to use ROCm version instead of HIP version - #1888
[ROCm] Rework ROCm build to use ROCm version instead of HIP version#1888sstamenk wants to merge 5 commits into
Conversation
|
Providing a table with various scenarios to better understand the logic. The library is named at build time and looked up by name at runtime. If the names don't match, loading fails.
When both In most cases we will hit the first scenario, and everything will be fine. Going forward the ROCm version will become even more common. If for some reason, there is a mismatch in version the user can always override them with either Going forward the hip version fallback can be entirely removed once a few versions pass and it is no longer needed for compatibility. |
91c27f2 to
eb72c84
Compare
|
The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update. |
|
#1889 should address issues seen when using TheRock builds (712 -> 82), this is something I have missed. @matthewdouglas We might want to hold off a bit on the CMake changes for a later date. The PR changes to the backend naming from |
|
@matthewdouglas It's available from version 2.10 https://github.com/pytorch/pytorch/blob/release/2.10/tools/generate_torch_version.py#L122 Windows only recently made it possible to do ROCm version lookup during build time (previously only HIP version was available via hipconfig), newer versions of ROCm have the $ROCM_PATH/.info/version file which has the ROCm version so waiting a bit is probably the right move so we can avoid the fallback and just use the ROCm version in the future. |
Use ROCm release metadata consistently at build and runtime while keeping packaged-binary fallbacks explicit.
eb818ab to
efd04b6
Compare
|
I've decided to revive this PR after some issues were raised with library detection during testing of one of the upcoming ROCm releases. I've updated the PR description to match the current behavior. |
Document the current same-major and ROCm cross-major selection priority more explicitly.
Illustrate older and newer same-major fallback ordering in the loader docstring.
Only pass shared libraries that exist to the packaging copy step.
Summary
Use the ROCm release version consistently when naming and selecting bitsandbytes native libraries. HIP and ROCm versions can diverge, so relying on
hipconfigortorch.version.hipalone can select a missing or incompatible binary.Changes
Build and packaging
COMPUTE_BACKEND=hipandBUILD_HIP).${ROCM_PATH}/.info/version,${ROCM_PATH}/core/.info/version, orrocm-sdk version.-DROCM_VERSION=<version>remains an optional override and accepts dotted or compact forms.ROCM_PATHfor Windows wheel-based SDK builds; Linux warns before defaulting to/opt/rocm.NO_HIPBLASLTpath.Runtime library selection
torch.version.rocm; warn and fall back totorch.version.hipwhen the ROCm field is unavailable.BNB_ROCM_VERSIONandBNB_CUDA_VERSION.Diagnostics and documentation
torch.version.rocmandtorch.version.hipseparately.Validation
pytest -q tests/test_cuda_setup_evaluator.py— 19 passedbash -n .github/scripts/build-rocm.sh.info/versionCompatibility
There is no backend rename in this PR: downstream builds using
-DCOMPUTE_BACKEND=hipcontinue to work. ROCm cross-major fallback is best-effort and emits a warning because compatibility and packaged GPU targets are not guaranteed.